Re: [Gluster-devel] Responsiblities of a release manager

2015-10-28 Thread Niels de Vos 
On Wed, Oct 28, 2015 at 04:17:57PM +0530, Raghavendra Talur wrote:
> Hi,
> 
> Here is a list that I could come up with while researching on
> responsibilities of a release manager.
> I request inputs from more people to make it more comprehensive and correct
> so that we can put it up in docs and point new release managers to it.

We have a doc for this already, but its lost in the master branch
somewhere...

  see doc/developer-guide/GlusterFS-Release-process.md from the master
  branch in a Gerrit (not GitHub) repository. I hope that this and other
  process documents move back to readthedocs.

> 
> ==
> 
> 1. You should have inherited a tracker bug with a good alias for your
> release version, if not please create one.

This should have been done when a release is made. The tracker for the
next minor release should be created at that time.

> 2. Use gerrit search something like [1] to find all the patches that were
> merged after previous release
> and ensure that the bugs they are using are already added to depends-on
> list of tracker bug.

Yes, something like this works. I mostly check the git repository from
the command line. There is no requirement for bugs to be listed on the
tracker bug. The ones on the tracker are most important, but others that
are not on the tracker can be fixed/merged never the less.

> 3. Create a bugzilla search for finding all dependent bugs for a release,
> something like [2]

That link does not work for me, you can not share saved bugzilla queries
easily :-/

> 4. Keep sending reminder mails on deadline approaching for merging of
> patches for the release and when tagging would be done.

Reminders to the maintainers list should be sufficient. Not sure if
there is additional value in letting the users-list know, maybe the
devel list too.

> QUESTION: Should we start making a commit along with a tag for a release
> where the commit updates a RELEASE-NOTES file in the repo with the same
> content as that would go later in the release announcement mails?

Yes, that is commonly done. The last commit for a release should be the
release-notes in the doc/release-notes/ directory. I do this for 3.5
like this:

  https://github.com/gluster/glusterfs/tree/release-3.5/doc/release-notes

> 5. On hitting deadline, send a mail informing of a temporary hold on
> merging of patches and start testing the branch comprehensively. Once
> sufficiently tested, make a tarball and ask the build team to make builds
> for various distributions.

Basically yes, but I mostly trust the regression tests to do the
testing. I only do some very basic tests. We really need an automated
test suite for releases, so that everyone runs the same tests.

> 6. Announce the release on mailing list, blogs etc with links to packages
> to be downloaded. Make sure you document all user facing changes and
> provide a list of bugs fixed.
> 
> 7. Use a script to mark all the depends-on bugs that were merged as closed
> and fixed in the release version.
> 
> 8. Create a tracker bug for next release in the same branch and move all
> the depends-on bugs that were not merged to the next release.

Looks pretty complete to me, most of these points have been documented
already too. Please send pull requests to improve the docs :)

Thanks,
Niels


> 
> 
> [1]
> https://review.gluster.org/#/q/project:glusterfs+branch:release-3.7+status:merged+after:2015-10-07
> [2]
> https://bugzilla.redhat.com/buglist.cgi?cmdtype=runnamed_id=4043168=glusterfs-3.7.6-depends-on
> ==
> 
> Thanks,
> Raghavendra Talur


signature.asc
Description: PGP signature
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] netbsd regressions failing

2015-10-28 Thread Kaushal M 
Could you link to a failed job?

On Wed, Oct 28, 2015 at 5:05 PM, Pranith Kumar Karampuri
 wrote:
> hi,
>   I have been trying to get netbsd tests to pass for some of my patches,
> netbsd74 was giving problem. I just rebooted nbslave74.cloud.gluster.org but
> even after that netbsd regressions are not triggered correctly. Any help is
> much appreciated.
>
> Pranith
>
> ___
> Gluster-devel mailing list
> Gluster-devel@gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-devel
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Glusterfs mainline BZs to close...

2015-10-28 Thread Niels de Vos 
On Wed, Oct 28, 2015 at 04:02:16PM +0530, Humble Devassy Chirammal wrote:
> Hi Niels,
> 
> >
>   Our shiny docs (or my bookmarks?) are broken again...
> 
> http://gluster.readthedocs.org/en/latest/Developer-guide/Bug%20report%20Life%20Cycle/
>   http://gluster.readthedocs.org/en/latest/Developer-guide/Bug%20Triage/
> 
> >
> As you know, the "Developer Guide" is now part of glusterfs source code (
> https://github.com/gluster/glusterfs/tree/master/doc/developer-guide) [1].
> The decision to split the glusterfs documentation  into three parts (
> developer spec/feature , Administration ) came late and it caused the
> bookmark to break.

Right, but I do not think the documentation of procedures and workflows
should be part of the developers guide. This counts for topics related
to bugs, releases and probably other things. Can we have a section on
readthedocs where procedures and workflows can be placed?

> Being Media Wiki  READONLY, we thought this type of documents can be part
> of Developer Guide for now. May be we need to sort the "developer guide" in
> source code repo  again and put it into correct buckets, but this needs
> some time and effort.

Yeah, we definitely should do that. And, also make sure that the old
wiki gets replaced by appropriate redirects to prevent confusion.

Thanks,
Niels

> 
> 
> [1]
> 
> Because of the gerrit plugin issue, the commits in gerrit has not been
> synced to github since Sep 10. However you can see the the change here
> http://review.gluster.org/#/c/12227/
> 
> --Humble
> 
> 
> On Mon, Oct 26, 2015 at 2:44 PM, Niels de Vos  wrote:
> 
> > On Wed, Oct 21, 2015 at 05:22:49AM -0400, Nagaprasad Sathyanarayana wrote:
> > > I came across the following BZs which are still open in mainline.  But
> > > they are fixed and made available in a upstream release.  Planning to
> > > close them this week, unless there are any objections.
> >
> > We have a policy to close bugs when their patches land in a released
> > version. The bugs against mainline will get closed when a release is
> > made that contains those fixes. For many of the current mainline bugs,
> > this would be the case when glusterfs-3.8 is released.
> >
> > What is the concern of having bugs against the mainline version open
> > until a release contains that particular fix? There are many bugs that
> > also get backports to stable versions (3.7, 3.6 and 3.5). Those bugs get
> > closed with each minor releases for that stable version.
> >
> > Of course we can change our policy to close mainline bugs earlier. But,
> > we need to be consistent in setting the rules for that, and document
> > them well. There is an ongoing task about automatically changing the
> > status of bugs when patches get posted/merged and releases made. Closing
> > mainline bugs should be part of that process.
> >
> > When do you suggest that a bug against mainline should be closed, when
> > one of the stable releases containst the fix, or when all of them do?
> > What version with fix should we point the users at when we closed a
> > mainline bug?
> >
> >   Our shiny docs (or my bookmarks?) are broken again...
> >
> > http://gluster.readthedocs.org/en/latest/Developer-guide/Bug%20report%20Life%20Cycle/
> >   http://gluster.readthedocs.org/en/latest/Developer-guide/Bug%20Triage/
> >
> >   This is the old contents:
> >
> > http://www.gluster.org/community/documentation/index.php/Bug_report_life_cycle
> >   http://www.gluster.org/community/documentation/index.php/Bug_triage
> >
> > I was about to suggest to send a pull request so that we can discuss
> > your proposal during the weekly Bug Triage meeting on Tuesdays.
> > Unfortunately I don't know where the latest documents moved to, so
> > please send your changes by email.
> >
> > Could you explain what Bugzilla query you used to find these bugs? We
> > have some keywords (like "Tracking") that should be handled with care,
> > and probably should not get closed even when patches were merged in
> > mainline and stable releases.
> >
> > Thanks,
> > Niels
> >
> >
> > >
> > >
> > 1211836,1212398,1211132,1215486,1213542,1212385,1210687,1209818,1210690,1215187,1215161,1214574,1218120,1217788,1216067,1213773,1210684,1209104,1217937,1200262,1204651,1211913,1211594,1163561,1176062,
> > >
> > 1219784,1176837,1208131,1200704,1220329,1221095,1172430,1219732,1219738,1213295,1212253,1211808,1207615,1216931,1224290,1217701,1223213,1223889,1223385,1221104,1221696,1219442,1224596,1165041,1225491,
> > >
> > 1221938,1226367,1215002,1222379,1221889,1220332,1223338,1224600,1222126,1212413,1211123,1225793,1226551,1218055,1220713,1223772,1222013,1227646,1228635,1227884,1224016,1223432,1227904,1228952,1228613,
> > >
> > 1209461,1226507,1225572,1227449,1220670,1225564,1225424,1200267,1229825,1230121,1228696,1228680,1229609,1229134,1231425,1229172,1232729,1208482,1169317,1180545,1231197,1188242,1229658,1232686,1234842,
> > >
> >

Re: [Gluster-devel] [Gluster-users] 3.7.5 upgrade issues

2015-10-28 Thread Raghavendra Talur 
I have filed a bug for this on bugzilla.
Here is the link https://bugzilla.redhat.com/show_bug.cgi?id=1276029.

Please cc yourself for updates on the bug.


Thanks,
Raghavendra Talur
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] netbsd regressions failing

2015-10-28 Thread Emmanuel Dreyfus 
On Wed, Oct 28, 2015 at 05:05:41PM +0530, Pranith Kumar Karampuri wrote:
>   I have been trying to get netbsd tests to pass for some of my patches,
> netbsd74 was giving problem. I just rebooted nbslave74.cloud.gluster.org
>  but even
> after that netbsd regressions are not triggered correctly. Any help is much
> appreciated.

Jenkins is the culprit: tcpdump tells me that build.gluster.org does not
even try to connect to nbslave74.cloud.gluster.org before deciding it fails.

https://build.gluster.org/computer/nbslave74.cloud.gluster.org/log
says "Ping failed. Terminating".

tcpdump shows continuous ping activity and their replies, but it
is from collector-dfw-50-56-142-141.monitoring.rackspacecloud.com
and not from build.gluster.org

I finally managed to recover it by disconnecting nbslave74 in 
jenkins web UI and launching the agent again. It is now running a 
job:
https://build.gluster.org/job/rackspace-netbsd7-regression-triggered/11217/console


-- 
Emmanuel Dreyfus
m...@netbsd.org
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] RFC: Gluster.Next: Where and how DHT2 work/code would be hosted

2015-10-28 Thread Shyam 

Sending this along again.

- Are we decided on *experimental*?
- If so, what else needs attention in the patch below?
- (Re)views please... (views as in "What are your views on this?", not 
"Have you viewed this?" ;) )


Shyam

On 10/12/2015 02:18 PM, Shyam wrote:

In an effort to push this along, update the change with suggested edits
and comments till now, request a review and further comments so that we
make this official at some (sooner) point in time.

http://review.gluster.org/#/c/12321/2
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

[Gluster-devel] Gerrit and Bugzilla usage

2015-10-28 Thread Raghavendra Talur 
While preparing the list of bugs for 3.7.6 I observed some patches that had
used bugs incorrectly.

Few things to keep in mind:

1. If you use the gerrit backport feature, take care to add the bug number
in topic section manually as it is not automatic. If not done, we lose
updates on bugzilla because scripts are triggered based on bug number
mentioned in topic.

2. Please don't use umbrella/tracker bugs for sending patches. It may
happen that not all bugs are fixed under a tracker bug within a release and
it creates ambiguity of whether to include it in list of bugs fixed or not.

3. Please don't use bugs which were closed as part of previous release.


Raghavendra Talur
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] RFC: Gluster.Next: Where and how DHT2 work/code would be hosted

2015-10-28 Thread Avra Sengupta 

My 2 cents on this:

The decision we take on this should have certain rationale, and I see 
two key things affecting that decision.
1. How much of the code we are planning to write now, is going to make 
it to the final product. If we are sure that a sizeable amount of code 
we are writing now, is gonna change over the course of time, then it 
makes sense to have that kinda development in experimental branch.
2. Is the code we are planning to deliver meddle with existing 
infrastructure. If so, then it should definitely go into experimental


Now analyzing NSR based on the above two constraints :
1. We definitely plan to use more than 80% of the code we write now, and 
plan to go about it in an incremental module by module kinda way.
2. We hardly have any overlap with existing infrastructure, and we can 
easily integrate with the current glusterd now, and move on to Glusterd 
2, as and when it is ready for consumption.


Based on the above analysis, I would say NSR can go right into master, 
and we can easily make sure that it's not built as part of any release. 
Now what NSR would follow, isn;t necessary for other translators to 
follow. For eg. I would think Glusterd2 would have to be in experimental 
coz it might meddle with current glusterd (but Atin would know better). 
The point being, the decision we take need not be a collective decision 
for all components, that would be enforced as a process, but rather 
should be a decision taken by individual components based on merit.



On 10/28/2015 08:32 PM, Shyam wrote:

Sending this along again.

- Are we decided on *experimental*?
- If so, what else needs attention in the patch below?
- (Re)views please... (views as in "What are your views on this?", not 
"Have you viewed this?" ;) )


Shyam

On 10/12/2015 02:18 PM, Shyam wrote:

In an effort to push this along, update the change with suggested edits
and comments till now, request a review and further comments so that we
make this official at some (sooner) point in time.

http://review.gluster.org/#/c/12321/2
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel


___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] VM fs becomes read only when one gluster node goes down

2015-10-28 Thread Niels de Vos 
On Tue, Oct 27, 2015 at 07:21:35PM +0100, André Bauer wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Hi Niels,
> 
> my network.ping-timeout was already set to 5 seconds.
> 
> Unfortunately it seems i dont have the timout setting in Ubuntu 14.04
> for my vda disk.
> 
> ls -al /sys/block/vda/device/ gives me only:
> 
> drwxr-xr-x 4 root root0 Oct 26 20:21 ./
> drwxr-xr-x 5 root root0 Oct 26 20:21 ../
> drwxr-xr-x 3 root root0 Oct 26 20:21 block/
> - -r--r--r-- 1 root root 4096 Oct 27 18:13 device
> lrwxrwxrwx 1 root root0 Oct 27 18:13 driver ->
> ../../../../bus/virtio/drivers/virtio_blk/
> - -r--r--r-- 1 root root 4096 Oct 27 18:13 features
> - -r--r--r-- 1 root root 4096 Oct 27 18:13 modalias
> drwxr-xr-x 2 root root0 Oct 27 18:13 power/
> - -r--r--r-- 1 root root 4096 Oct 27 18:13 status
> lrwxrwxrwx 1 root root0 Oct 26 20:21 subsystem ->
> ../../../../bus/virtio/
> - -rw-r--r-- 1 root root 4096 Oct 26 20:21 uevent
> - -r--r--r-- 1 root root 4096 Oct 26 20:21 vendor
> 
> 
> Is the qourum setting a problem, if you only have 2 replicas?
> 
> My volume has this quorum options set:
> 
> cluster.quorum-type: auto
> cluster.server-quorum-type: server
> 
> As i understand the documentation (
> https://access.redhat.com/documentation/en-US/Red_Hat_Storage/2.0/html/A
> dministration_Guide/sect-User_Guide-Managing_Volumes-Quorum.html
> ), cluster.server-quorum-ratio is set to "< 50%" by default, which can
> never happen if you only have 2 replicas and one node goes down, right?
> 
> Do in need cluster.server-quorum-ratio = 50% in this case?

Replica 2 for VM storage is troublesome. Sahine just responded very
nicely to a very similar email:

  http://thread.gmane.org/gmane.comp.file-systems.gluster.user/22818/focus=22823

HTH,
Niels


signature.asc
Description: PGP signature
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

[Gluster-devel] Gluster 3.7.6 release preparation

2015-10-28 Thread Raghavendra Talur 
Hi All,

3.7.6 is scheduled to be released by the end of this month.[1]

If you want to propose a bug to go in this release, please add it to the
tracker bug. [2]
If the patch for the proposed bugs are merged by 30 October they will make
it into this release.

List of patches already merged in 3.7 after 3.7.5 release. [3]
List of bugs from this list that I have added in depends section of 3.7.6
tracker.[4]

List of patches open for review in 3.7 branch. [5]
Once again, requesting all of you to add bugs to this tracker if you want
to see it in 3.7.6 release.



Raghavendra Talur


[1] http://www.gluster.org/community/release-schedule/
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1275914
[3]
https://review.gluster.org/#/q/project:glusterfs+branch:release-3.7+status:merged+after:2015-10-07
[4]
https://bugzilla.redhat.com/buglist.cgi?cmdtype=runnamed_id=4043168=glusterfs-3.7.6-depends-on
[5]
https://review.gluster.org/#/q/project:glusterfs+branch:release-3.7+status:open
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Glusterfs mainline BZs to close...

2015-10-28 Thread Humble Devassy Chirammal 
Hi Niels,

>
  Our shiny docs (or my bookmarks?) are broken again...

http://gluster.readthedocs.org/en/latest/Developer-guide/Bug%20report%20Life%20Cycle/
  http://gluster.readthedocs.org/en/latest/Developer-guide/Bug%20Triage/

>
As you know, the "Developer Guide" is now part of glusterfs source code (
https://github.com/gluster/glusterfs/tree/master/doc/developer-guide) [1].
The decision to split the glusterfs documentation  into three parts (
developer spec/feature , Administration ) came late and it caused the
bookmark to break.

Being Media Wiki  READONLY, we thought this type of documents can be part
of Developer Guide for now. May be we need to sort the "developer guide" in
source code repo  again and put it into correct buckets, but this needs
some time and effort.


[1]

Because of the gerrit plugin issue, the commits in gerrit has not been
synced to github since Sep 10. However you can see the the change here
http://review.gluster.org/#/c/12227/

--Humble


On Mon, Oct 26, 2015 at 2:44 PM, Niels de Vos  wrote:

> On Wed, Oct 21, 2015 at 05:22:49AM -0400, Nagaprasad Sathyanarayana wrote:
> > I came across the following BZs which are still open in mainline.  But
> > they are fixed and made available in a upstream release.  Planning to
> > close them this week, unless there are any objections.
>
> We have a policy to close bugs when their patches land in a released
> version. The bugs against mainline will get closed when a release is
> made that contains those fixes. For many of the current mainline bugs,
> this would be the case when glusterfs-3.8 is released.
>
> What is the concern of having bugs against the mainline version open
> until a release contains that particular fix? There are many bugs that
> also get backports to stable versions (3.7, 3.6 and 3.5). Those bugs get
> closed with each minor releases for that stable version.
>
> Of course we can change our policy to close mainline bugs earlier. But,
> we need to be consistent in setting the rules for that, and document
> them well. There is an ongoing task about automatically changing the
> status of bugs when patches get posted/merged and releases made. Closing
> mainline bugs should be part of that process.
>
> When do you suggest that a bug against mainline should be closed, when
> one of the stable releases containst the fix, or when all of them do?
> What version with fix should we point the users at when we closed a
> mainline bug?
>
>   Our shiny docs (or my bookmarks?) are broken again...
>
> http://gluster.readthedocs.org/en/latest/Developer-guide/Bug%20report%20Life%20Cycle/
>   http://gluster.readthedocs.org/en/latest/Developer-guide/Bug%20Triage/
>
>   This is the old contents:
>
> http://www.gluster.org/community/documentation/index.php/Bug_report_life_cycle
>   http://www.gluster.org/community/documentation/index.php/Bug_triage
>
> I was about to suggest to send a pull request so that we can discuss
> your proposal during the weekly Bug Triage meeting on Tuesdays.
> Unfortunately I don't know where the latest documents moved to, so
> please send your changes by email.
>
> Could you explain what Bugzilla query you used to find these bugs? We
> have some keywords (like "Tracking") that should be handled with care,
> and probably should not get closed even when patches were merged in
> mainline and stable releases.
>
> Thanks,
> Niels
>
>
> >
> >
> 1211836,1212398,1211132,1215486,1213542,1212385,1210687,1209818,1210690,1215187,1215161,1214574,1218120,1217788,1216067,1213773,1210684,1209104,1217937,1200262,1204651,1211913,1211594,1163561,1176062,
> >
> 1219784,1176837,1208131,1200704,1220329,1221095,1172430,1219732,1219738,1213295,1212253,1211808,1207615,1216931,1224290,1217701,1223213,1223889,1223385,1221104,1221696,1219442,1224596,1165041,1225491,
> >
> 1221938,1226367,1215002,1222379,1221889,1220332,1223338,1224600,1222126,1212413,1211123,1225793,1226551,1218055,1220713,1223772,1222013,1227646,1228635,1227884,1224016,1223432,1227904,1228952,1228613,
> >
> 1209461,1226507,1225572,1227449,1220670,1225564,1225424,1200267,1229825,1230121,1228696,1228680,1229609,1229134,1231425,1229172,1232729,1208482,1169317,1180545,1231197,1188242,1229658,1232686,1234842,
> >
> 1235216,1235359,1235195,1235007,1232238,1233617,1235542,1233162,1233258,1193388,1238072,1236270,1237381,1238508,1230007,1210689,1240254,1240564,1241153,1193636,1132465,1226717,1242609,1238747,1242875,
> >
> 1226279,1240210,1232678,1242254,1232391,1242570,1235231,1240654,1240284,1215117,1240184,1228520,1244165,1243187,1243774,1209430,1196027,1232572,1202244,1229297,1246052,1246082,1238135,1245547,1234819,
> >
> 1224611,1221914,1207134,1245981,1246432,1178619,1243890,1240598,1240949,1247930,1247108,1245544,1238936,1232420,1245142,1226223,1250441,1229860,1245276,1246275,1250582,1249499,1231437,1241274,1212437,
> >
>

[Gluster-devel] Regression error

2015-10-28 Thread Saravanakumar Arumugam 

Hi,
Facing weird Linux regression errors like:

Building remotely onslave25.cloud.gluster.org 
  (smoke_tests rackspace_regression_2gb glusterfs-devrpms) in workspace /home/jenkins/root/workspace/rackspace-regression-2GB-triggered

 > git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > git config remote.origin.url git://review.gluster.org/glusterfs.git # 
timeout=10
Fetching upstream changes from git://review.gluster.org/glusterfs.git
 > git --version # timeout=10
 > git -c core.askpass=true fetch --tags --progress 
git://review.gluster.org/glusterfs.git  refs/changes/27/12427/3
ERROR: Error fetching remote repo 'origin'
ERROR : Error fetching 
remote repo 'origin'
Finished : FAILURE



and for NETBSD regression :


Building remotely onnbslave74.cloud.gluster.org 
  (netbsd7_regression) in workspace /home/jenkins/root/workspace/rackspace-netbsd7-regression-triggered

java.io.IOException: remote file operation failed: 
/home/jenkins/root/workspace/rackspace-netbsd7-regression-triggered at 
hudson.remoting.Channel@7e66a3a:nbslave74.cloud.gluster.org: 
hudson.remoting.ChannelClosedException: channel is already closed
at hudson.FilePath.act(FilePath.java:987)
at hudson.FilePath.act(FilePath.java:969)
at hudson.FilePath.mkdirs(FilePath.java:1152)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1269)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:610)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:532)
at hudson.model.Run.execute(Run.java:1744)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:98)
at hudson.model.Executor.run(Executor.java:374)
Caused by: hudson.remoting.ChannelClosedException: channel is already closed
at hudson.remoting.Channel.send(Channel.java:550)
at hudson.remoting.Request.call(Request.java:129)
at hudson.remoting.Channel.call(Channel.java:752)
at hudson.FilePath.act(FilePath.java:980)
... 10 more
Caused by: java.io.IOException
at hudson.remoting.Channel.close(Channel.java:1110)
at hudson.slaves.ChannelPinger$1.onDead(ChannelPinger.java:118)
at hudson.remoting.PingThread.ping(PingThread.java:126)
at hudson.remoting.PingThread.run(PingThread.java:85)
Caused by: java.util.concurrent.TimeoutException: Ping started at 1445955215550 
hasn't completed by 144595540
... 2 more
Finished: FAILURE


Please help.

--
Saravana

___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

[Gluster-devel] Responsiblities of a release manager

2015-10-28 Thread Raghavendra Talur 
Hi,

Here is a list that I could come up with while researching on
responsibilities of a release manager.
I request inputs from more people to make it more comprehensive and correct
so that we can put it up in docs and point new release managers to it.

==

1. You should have inherited a tracker bug with a good alias for your
release version, if not please create one.

2. Use gerrit search something like [1] to find all the patches that were
merged after previous release
and ensure that the bugs they are using are already added to depends-on
list of tracker bug.

3. Create a bugzilla search for finding all dependent bugs for a release,
something like [2]

4. Keep sending reminder mails on deadline approaching for merging of
patches for the release and when tagging would be done.

QUESTION: Should we start making a commit along with a tag for a release
where the commit updates a RELEASE-NOTES file in the repo with the same
content as that would go later in the release announcement mails?

5. On hitting deadline, send a mail informing of a temporary hold on
merging of patches and start testing the branch comprehensively. Once
sufficiently tested, make a tarball and ask the build team to make builds
for various distributions.

6. Announce the release on mailing list, blogs etc with links to packages
to be downloaded. Make sure you document all user facing changes and
provide a list of bugs fixed.

7. Use a script to mark all the depends-on bugs that were merged as closed
and fixed in the release version.

8. Create a tracker bug for next release in the same branch and move all
the depends-on bugs that were not merged to the next release.


[1]
https://review.gluster.org/#/q/project:glusterfs+branch:release-3.7+status:merged+after:2015-10-07
[2]
https://bugzilla.redhat.com/buglist.cgi?cmdtype=runnamed_id=4043168=glusterfs-3.7.6-depends-on
==

Thanks,
Raghavendra Talur
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Regression error

2015-10-28 Thread Kaushal M 
When did these failures happen? There was a problem with
review.gluster.org yesterday, which was causing cloning failures. If
this is still happening could you point out where these failures are
occurring.


On Wed, Oct 28, 2015 at 4:17 PM, Saravanakumar Arumugam
 wrote:
> Hi,
> Facing weird Linux regression errors like:
>
> Building remotely on slave25.cloud.gluster.org (smoke_tests
> rackspace_regression_2gb glusterfs-devrpms) in workspace
> /home/jenkins/root/workspace/rackspace-regression-2GB-triggered
>  > git rev-parse --is-inside-work-tree # timeout=10
> Fetching changes from the remote Git repository
>  > git config remote.origin.url git://review.gluster.org/glusterfs.git #
> timeout=10
> Fetching upstream changes from git://review.gluster.org/glusterfs.git
>  > git --version # timeout=10
>  > git -c core.askpass=true fetch --tags --progress
> git://review.gluster.org/glusterfs.git  refs/changes/27/12427/3
> ERROR: Error fetching remote repo 'origin'
> ERROR: Error fetching remote repo 'origin'
> Finished: FAILURE
>
>
>
> and for NETBSD regression :
>
>
> Building remotely on nbslave74.cloud.gluster.org (netbsd7_regression) in
> workspace
> /home/jenkins/root/workspace/rackspace-netbsd7-regression-triggered
> java.io.IOException: remote file operation failed:
> /home/jenkins/root/workspace/rackspace-netbsd7-regression-triggered at
> hudson.remoting.Channel@7e66a3a:nbslave74.cloud.gluster.org:
> hudson.remoting.ChannelClosedException: channel is already closed
>   at hudson.FilePath.act(FilePath.java:987)
>   at hudson.FilePath.act(FilePath.java:969)
>   at hudson.FilePath.mkdirs(FilePath.java:1152)
>   at hudson.model.AbstractProject.checkout(AbstractProject.java:1269)
>   at
> hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:610)
>   at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
>   at
> hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:532)
>   at hudson.model.Run.execute(Run.java:1744)
>   at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
>   at hudson.model.ResourceController.execute(ResourceController.java:98)
>   at hudson.model.Executor.run(Executor.java:374)
> Caused by: hudson.remoting.ChannelClosedException: channel is already closed
>   at hudson.remoting.Channel.send(Channel.java:550)
>   at hudson.remoting.Request.call(Request.java:129)
>   at hudson.remoting.Channel.call(Channel.java:752)
>   at hudson.FilePath.act(FilePath.java:980)
>   ... 10 more
> Caused by: java.io.IOException
>   at hudson.remoting.Channel.close(Channel.java:1110)
>   at hudson.slaves.ChannelPinger$1.onDead(ChannelPinger.java:118)
>   at hudson.remoting.PingThread.ping(PingThread.java:126)
>   at hudson.remoting.PingThread.run(PingThread.java:85)
> Caused by: java.util.concurrent.TimeoutException: Ping started at
> 1445955215550 hasn't completed by 144595540
>   ... 2 more
> Finished: FAILURE
>
>
> Please help.
>
> --
> Saravana
>
>
> ___
> Gluster-devel mailing list
> Gluster-devel@gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-devel
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Regression error

2015-10-28 Thread Saravanakumar Arumugam 

Facing issues with these patches:
http://review.gluster.org/#/c/12427/
http://review.gluster.org/#/c/12428/
http://review.gluster.org/#/c/12429/

Please check.
--
Saravana

On 10/28/2015 04:28 PM, Kaushal M wrote:

When did these failures happen? There was a problem with
review.gluster.org yesterday, which was causing cloning failures. If
this is still happening could you point out where these failures are
occurring.


On Wed, Oct 28, 2015 at 4:17 PM, Saravanakumar Arumugam
 wrote:

Hi,
Facing weird Linux regression errors like:

Building remotely on slave25.cloud.gluster.org (smoke_tests
rackspace_regression_2gb glusterfs-devrpms) in workspace
/home/jenkins/root/workspace/rackspace-regression-2GB-triggered
  > git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
  > git config remote.origin.url git://review.gluster.org/glusterfs.git #
timeout=10
Fetching upstream changes from git://review.gluster.org/glusterfs.git
  > git --version # timeout=10
  > git -c core.askpass=true fetch --tags --progress
git://review.gluster.org/glusterfs.git  refs/changes/27/12427/3
ERROR: Error fetching remote repo 'origin'
ERROR: Error fetching remote repo 'origin'
Finished: FAILURE



and for NETBSD regression :


Building remotely on nbslave74.cloud.gluster.org (netbsd7_regression) in
workspace
/home/jenkins/root/workspace/rackspace-netbsd7-regression-triggered
java.io.IOException: remote file operation failed:
/home/jenkins/root/workspace/rackspace-netbsd7-regression-triggered at
hudson.remoting.Channel@7e66a3a:nbslave74.cloud.gluster.org:
hudson.remoting.ChannelClosedException: channel is already closed
at hudson.FilePath.act(FilePath.java:987)
at hudson.FilePath.act(FilePath.java:969)
at hudson.FilePath.mkdirs(FilePath.java:1152)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1269)
at
hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:610)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:532)
at hudson.model.Run.execute(Run.java:1744)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:98)
at hudson.model.Executor.run(Executor.java:374)
Caused by: hudson.remoting.ChannelClosedException: channel is already closed
at hudson.remoting.Channel.send(Channel.java:550)
at hudson.remoting.Request.call(Request.java:129)
at hudson.remoting.Channel.call(Channel.java:752)
at hudson.FilePath.act(FilePath.java:980)
... 10 more
Caused by: java.io.IOException
at hudson.remoting.Channel.close(Channel.java:1110)
at hudson.slaves.ChannelPinger$1.onDead(ChannelPinger.java:118)
at hudson.remoting.PingThread.ping(PingThread.java:126)
at hudson.remoting.PingThread.run(PingThread.java:85)
Caused by: java.util.concurrent.TimeoutException: Ping started at
1445955215550 hasn't completed by 144595540
... 2 more
Finished: FAILURE


Please help.

--
Saravana


___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel


___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel