Pull Requests for Deuterium

Horizon_Brave · 2016-08-08 17:47:57

Hi all,
I was wonder if it's acceptable to have a running list of pulls and changes that are expected, proposed and being worked on for the next release. Sort of a "Definite" (green), "In Progress/If Time Permits" (yellow), or Proposed/Suggested (red) sort of list here. I know github exists, but I swear that website still confuses me at times, so I figured it may be nice to keep up with the updates on here as well for the sake of the forum community as well. Once Deuterium is pushed out officially, this can be used as a checklist or something of the sort.. Just to provide some visibility into what's being considered etc...

Head_on_a_Stick · 2016-08-08 19:39:55

Horizon_Brave wrote:

I was wonder if it's acceptable to have a running list of pulls and changes that are expected, proposed and being worked on for the next release. Sort of a "Definite" (green), "In Progress/If Time Permits" (yellow), or Proposed/Suggested (red) sort of list here.

Yes, that might be useful -- thanks HB

You can check the Pull Requests from github and then post here when they change, I suppose.

Horizon_Brave · 2016-08-08 21:55:28

Cool, if I post anything that's not really meant to be 'seen' yet, or is not really accurate or planned for Deuterium, do let me know so I can edit.

Anyway so to get things started, I'll begin with the accepted pull requests. As far as I can tell, nothing has been officially accepted into master (future Deuterium). So all information is commits (proposed changes).

bunsen-pipemenus repo:
Commits :
bin/bl-compositor
bin/bl-kb-pipemenu
bin/bl-places-pipemenu
bin/bl-sshconfig-pipemenu

bunsen-utilities repo:

Commits:
bin/bl-aerosnap
bin/bl-exit
bin/bl-hotcorners
bin/bl-kb
bin/bl-tint2-session
bin/bl-tint2restart
bin/bl-tint2zen
bl-exitrc

*The utilities branch for Deuterium reports that it's 7 commit changes 'behind' the current B.L master. Not sure why this would be though? Is this normal when branching and merging? I would expect a branch to always be "ahead" of it's original master?*

No changes in bunsenlab-netinstall

Bunsen-welcome (lots 'o changes)
Commits
bl-welcome
welcome/add-debian-backports
welcome/apt-upgrade
welcome/check-repos
welcome/intro

New Additions:
welcome/add-bunsen-backports (completely new addition in Deuterium)

bunsen-configs repo:

Commits

bl-alternatives
bl-gvim
bl-user-setup
debian/bunsen-configs.install
skel/.config/compton.conf
skel/.config/openbox/autostart
skel/.config/openbox/pipemenus.rc
skel/.config/openbox/rc.xml
skel/.config/volumeicon/volumeicon
skel/.config/xfce4/xfconf/xfce-perchannel-xml/thunar.xml

New Additions:
asound.conf
bl-start-pulseaudio-x11
skel/.config/autostart/pulseaudio.desktop

bunsen-common (little change)
Commits:
bl-include.cfg

bunsen-faenza-icon-theme repo

Commits:
debian/links

Again, I'm all thumbs with github, so if I missed anything, or misrepresented anything please feel free to edit, or let me know. I'll be adding more detail to the changes proposed in the commits. Just summarizing changes from what I can understand, and opening discussion to anyone who's not sure about rather something is going to be fixed/patched/changed etc....

Surprisingly no changes in Deuterium to Tint2??

Last edited by Horizon_Brave (2016-08-08 21:57:29)

johnraff · 2016-08-10 06:23:46

Horizon_Brave wrote:

Cool, if I post anything that's not really meant to be 'seen' ...

BunsenLabs' GitHub repos are a public space where everything is meant to be seen. Post anything you like.

Unia · 2016-08-10 08:25:37

I agree with @johnraff, but your git terminology is a bit off. See the GitHub Glossary page for an elaborate list of terminology.

Horizon_Brave wrote:

Anyway so to get things started, I'll begin with the accepted pull requests. As far as I can tell, nothing has been officially accepted into master (future Deuterium). So all information is commits (proposed changes).

Master is the branch corresponding to what is currently packaged; master is "current". The Deuterium branch contains work (new features and code refactoring, mostly, as bug fixes et cetera are applied to master to bring them to the current packages) that will get into Deuterium. This does not mean that they haven't been officially accepted; they're just in a new branch because they require more testing and because we need a place to provide fixes to the current releases.

This is just one way to go about it; other projects choose to do it the other way around. They consider the master branch to be the (main, some features are developed in their dedicated feature branches) development branch and make a branch for each release.

As you can see in the glossary I linked to, a "commit" is not a proposed change.

Horizon_Brave wrote:

*The utilities branch for Deuterium reports that it's 7 commit changes 'behind' the current B.L master. Not sure why this would be though? Is this normal when branching and merging? I would expect a branch to always be "ahead" of it's original master?*

This is normal behavior. All branches together form a "tree", see GitHub's network graph. Once a branch has been split from another, commits can be made to either one. In this case, bug fixes have gone into master (and are thus not present in the Deuterium branch) and new features have gone into Deuterium (and are thus not present in the master branch). This will all be resolved when merging the Deuterium branch into the master branch, but it can lead to conflicts.

Horizon_Brave wrote:

Again, I'm all thumbs with github, so if I missed anything, or misrepresented anything please feel free to edit, or let me know. I'll be adding more detail to the changes proposed in the commits. Just summarizing changes from what I can understand, and opening discussion to anyone who's not sure about rather something is going to be fixed/patched/changed etc....

See also our GitLog.

Horizon_Brave · 2016-08-10 17:45:51

Unia wrote:

Master is the branch corresponding to what is currently packaged; master is "current". The Deuterium branch contains work (new features and code refactoring, mostly, as bug fixes et cetera are applied to master to bring them to the current packages) that will get into Deuterium. This does not mean that they haven't been officially accepted; they're just in a new branch because they require more testing and because we need a place to provide fixes to the current releases.

Right, this I knew.

Unia wrote:

This is just one way to go about it; other projects choose to do it the other way around. They consider the master branch to be the (main, some features are developed in their dedicated feature branches) development branch and make a branch for each release.
As you can see in the glossary I linked to, a "commit" is not a proposed change.

Wow...ehh that seems backwards to me...even just logically. It seems like it'd be too much branching off.. Myself atleast, I think the current method of using the branches as the "testing labs" and then have the changes ported into the Master branch just makes more sense.

Horizon_Brave wrote:

*The utilities branch for Deuterium reports that it's 7 commit changes 'behind' the current B.L master. Not sure why this would be though? Is this normal when branching and merging? I would expect a branch to always be "ahead" of it's original master?*

Unia wrote:

This is normal behavior. All branches together form a "tree", see GitHub's network graph. Once a branch has been split from another, commits can be made to either one. In this case, bug fixes have gone into master (and are thus not present in the Deuterium branch) and new features have gone into Deuterium (and are thus not present in the master branch). This will all be resolved when merging the Deuterium branch into the master branch, but it can lead to conflicts.

Ahh I see. So it's just the normal 'ebb and flow' of the change process. Your post has been much appreciated Unia

Last edited by Horizon_Brave (2016-08-10 17:46:22)

Unia · 2016-08-10 19:23:29

Horizon_Brave wrote:

Unia wrote:
This is just one way to go about it; other projects choose to do it the other way around. They consider the master branch to be the (main, some features are developed in their dedicated feature branches) development branch and make a branch for each release.
As you can see in the glossary I linked to, a "commit" is not a proposed change.
Wow...ehh that seems backwards to me...even just logically. It seems like it'd be too much branching off.. Myself atleast, I think the current method of using the branches as the "testing labs" and then have the changes ported into the Master branch just makes more sense.

The advantage here is that it is easier to backport bug (/security) fixes. Also, when using branches for releases, there is nothing stopping you from using development branches -- branches (in git at least) are cheap! See for example the branches of Eye of GNOME; in the top right there is a tiny drop down menu saying "master". Clicking on it shows all branches inside that git repo.

Using feature branches also becomes a bit less relevant when not using GitHub, as GNOME does.

#1 2016-08-08 17:47:57

Pull Requests for Deuterium

#2 2016-08-08 19:39:55

Re: Pull Requests for Deuterium

#3 2016-08-08 21:55:28

Re: Pull Requests for Deuterium

#4 2016-08-10 06:23:46

Re: Pull Requests for Deuterium

#5 2016-08-10 08:25:37

Re: Pull Requests for Deuterium

#6 2016-08-10 17:45:51

Re: Pull Requests for Deuterium

#7 2016-08-10 19:23:29

Re: Pull Requests for Deuterium

Board footer